Closed
Bug 519797
Opened 16 years ago
Closed 16 years ago
[Gmail] Thunderbird creates spurious Trash folder (autoconfig doesn't generate mail.server.serverN.trash_folder_name, then root-level Trash is created by existence check of trash folder even though [Gmail]/Trash is already used as trash folder)
Categories
(MailNews Core :: Account Manager, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
Thunderbird 3.0rc1
People
(Reporter: squib, Assigned: Bienvenu)
References
(Blocks 1 open bug)
Details
(Keywords: fixed-seamonkey2.0.1, regression, Whiteboard: [no l10n impact][ready to land])
Attachments
(2 files)
12.13 KB,
image/png
|
Details | |
3.83 KB,
patch
|
standard8
:
review+
standard8
:
superreview+
|
Details | Diff | Splinter Review |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20090930 Shredder/3.0pre
With a Gmail IMAP account, Thunderbird creates a second Trash folder at the root level (under both Windows and Linux). This issue may go beyond Gmail, but that's where I'm seeing it, and I haven't had a chance to test on other IMAP servers yet.
Some things I've noticed:
1) It does create a folder on the server (shown as [IMAP]/Trash in Gmail).
2) Deleting the folder works (both client and server side), but it will reappear when you restart Thunderbird.
3) If the bogus trash folder is present when you start Thunderbird, it appears with the trashcan icon for a few seconds and then reverts to a regular folder icon.
4) Deleted messages go to the proper folder ([Gmail]/Trash), so the bogus folder isn't actually doing anything.
This seems like something that must have been reported already, but I couldn't find anything that matched.
Comment 1•16 years ago
|
||
(Q1) How did you create the Gmail IMAP account with Tb?
(A) Tb3: File/New/Mail Account (autoconfig)
(B) Tb3: Account Settings/Add Account, Gmail IMAP (Account Wizard for Gmail IMAP)
(C) Tb3(or Tb2): Account Settings/Add Account, Email Account, IMAP
(If Tb 2, File/New/Account corresponds to this)
(Q2) Check special folder name/path setting in your prefs.js.
Tools/Options/Advanced/General, Config Editor, Filter: folder
Name/path for trash, drafts, ... etc. are specified in ###folder$$$.
(### and $$$ depends on entry)
What is set for trash folder?
Is there any folder setting which points root-level Trash?
(Q3) Do you use other IMAP client who accesses the Gmail IMAP account?
(At least two IMAP clients exist in your case. Tb on Linux and Tb on Win.)
If other client points "Trash", he creates, subscribes IMAP folder named
"Trash"(==Gmail Label of "[Imap]/Trash").
I'm a such user. Sm 1, Tb 2, a Tb 3's profile uses "Trash" as trash folder,
and Tb 3's another profile uses "[Gmail]/Trash"(=="Trash" at Gmail Web).
Reporter | ||
Comment 2•16 years ago
|
||
(A1) I created the account via autoconfig from a fresh profile.
(A2) I don't have a pref for the trash folder, though I do have prefs for archives, sent mail (fcc), drafts, and templates (stationery).
(A3) The only IMAP clients I use with this account are two instances of TB3 for testing. If I log into Gmail's web interface and fix the account's folders (i.e. remove [IMAP]/Gmail) and then, from a fresh profile, use autoconfig to set up a new account for it in TB3, the same thing happens.
Comment 3•16 years ago
|
||
(In reply to comment #2)
> (A2) I don't have a pref for the trash folder, though I do have prefs for
> archives, sent mail (fcc), drafts, and templates (stationery).
It's the reason. If no mail.server.serverN.trash_folder_name, "Trash" is used.
> mail.server.serverN.trash_folder_name = Trash
Do you select "Move to Trash" model via Account Settings/Server Settings by yourself? Or "Move to Trash" model is set by autoconfig since initial?.
Go Server Settings. Is "Trash" displayed as folder of "move to trash" model?
Save setting by "OK" button. Is mail.server.serverN.trash_folder_name created?
Workaround:
(1) At Server Settings, select [Gmail]/Trash as folder of "move to trash" model.
-> mail.server.serverN.trash_folder_name = [Gmail]/Trash is created.
Note: "Trash" is displayed. Unable to know "Trash" or "[Gmail]/Trash".
It's already known issue.
(2) If you want to use recomended delete model for Gmail IMAP,
change delete model to "Remove it immediately".
(3) Restart Tb.
Note: Restart is possibly needd for icon change, for correct status change
of "trash folder" or not, etc. Some bug are seen for such problem.
Reporter | ||
Comment 4•16 years ago
|
||
(In reply to comment #3)
> It's the reason. If no mail.server.serverN.trash_folder_name, "Trash" is used.
Yeah, I kinda figured the underlying issue was that autoconfig wasn't picking the trash folder properly for Gmail.
> Do you select "Move to Trash" model via Account Settings/Server Settings by
> yourself? Or "Move to Trash" model is set by autoconfig since initial?.
This is the default configuration that you get from going through autoconfig. The workaround does work, which is good (it's more or less what I did on TB2 for my real account; this one is just for testing), but autoconfig should catch this.
The part that confuses me is that by default, Thunderbird claims that it's putting deleted mail into Trash instead of [Gmail]/Trash. However, actually deleting a message puts it in [Gmail]/Trash anyway. That may just be Gmail's IMAP implementation being weird as usual, though.
I think the take-home from this is: autoconfig needs to set trash_folder_name as appropriate. I'll look into writing up a patch for it, though I'm not very familiar with the autoconfig code.
Comment 5•16 years ago
|
||
(In reply to comment #4)
> The part that confuses me is that by default, Thunderbird claims that it's
> putting deleted mail into Trash instead of [Gmail]/Trash. However, actually
> deleting a message puts it in [Gmail]/Trash anyway. That may just be Gmail's
> IMAP implementation being weird as usual, though.
Tb 3 supports XLIST(see Bug 476260) which Gmail IMAP suports and uses. So Tb can know about folder which Gmail considers "trash" via XLIST command. By the feature and enhancements for Gmail IMAP support, Tb can use [Gmail]/Trash as "trash" after ordinal/successful login to Gmail IMAP server.
On the other hand, standard/ordinal/traditional check for "trash" is based on mail.server.serverN.trash_folder_name only, and existence check is executed earlier stage in startup than ordinal login to server by "Check new message at startup". Root-level "Trash" is probably created by the existence check.
Comment 6•16 years ago
|
||
Problem was reproduced with Tb 3.0b4 9/30 build.
(1) New profile, define Gmail account by autoconfig.
mail.server.serverN.trash_folder_name is not generated.
(2) Restart Tb, click Inbox to force login.
(3) Delete root-level Trash -> Moved under [Gmail]/Trash. Empty Trash
(4) Check subscription list -> no Trash
(5) Collapse account, expand account
-> root-level Trash is created. Icon=Trash can icon
(created by existence check)
(6) Move mouse on root-level Trash -> Icon is changed to ordinal folder icon.
Because Tb already uses [Gmail]/Trash as trash folder, and no prefs.js entry
points root-level Trash, the created Trash is ordinal folder.
Confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: [Gmail] Thunderbird creates spurious Trash folder → [Gmail] Thunderbird creates spurious Trash folder (autoconfig doesn't generate mail.server.serverN.trash_folder_name, then root-level Trash is created by existence check of trash folder even though [Gmail]/Trash is already used as trash folder)
Updated•16 years ago
|
Component: Networking: IMAP → Account Manager
OS: Linux → All
QA Contact: networking.imap → account-manager
Version: unspecified → 1.9.1 Branch
Updated•16 years ago
|
Blocks: tb-gmailWIP
Reporter | ||
Comment 7•16 years ago
|
||
Does the use of XLIST mean that it's impossible to specify a custom Trash folder? That doesn't seem to work either. That doesn't bother me from a practical standpoint, but if TB is going to use the response from XLIST no matter what, then it shouldn't let users "pick" the trash folder for that account.
Updated•16 years ago
|
Flags: blocking-thunderbird3?
Assignee | ||
Comment 8•16 years ago
|
||
taking - I had this all working at one point
Assignee: nobody → bienvenu
Flags: blocking-thunderbird3? → blocking-thunderbird3+
Assignee | ||
Comment 9•16 years ago
|
||
I think I broke this when all the kerfuffle erupted about not respecting imap subscription with gmail. It might be fairly easy to fix the trash issue.
Assignee | ||
Comment 10•16 years ago
|
||
This fixes the regression, by moving some code around so that we propagate the xlist flags to the mailbox specs before we start checking for the gmail trash, and make sure we clear the trash exists flag *before* we've done xlist, not after.
Attachment #407907 -
Flags: superreview?(bugzilla)
Attachment #407907 -
Flags: review?(bugzilla)
Assignee | ||
Comment 11•16 years ago
|
||
this is a regression in 3.0, from b3 or b4 to now (though not from 2.0)
Status: NEW → ASSIGNED
Keywords: regression
Assignee | ||
Comment 12•16 years ago
|
||
this is probably a good litmus test to have - you do need to start off with a gmail account that doesn't have a TB-created Trash folder, of course.
Flags: in-litmus?
Updated•16 years ago
|
Whiteboard: [no l10n impact][needs review standard8]
Updated•16 years ago
|
Attachment #407907 -
Flags: superreview?(bugzilla)
Attachment #407907 -
Flags: superreview+
Attachment #407907 -
Flags: review?(bugzilla)
Attachment #407907 -
Flags: review+
Updated•16 years ago
|
Whiteboard: [no l10n impact][needs review standard8] → [no l10n impact][ready to land]
Target Milestone: --- → Thunderbird 3.0rc1
Assignee | ||
Comment 13•16 years ago
|
||
fix landed on the trunk. I'll pull a branch repo and push there as well...
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: Thunderbird 3.0rc1 → Thunderbird 3.1a1
Assignee | ||
Comment 14•16 years ago
|
||
fix pushed to 3.0 release repo as well.
Target Milestone: Thunderbird 3.1a1 → Thunderbird 3.0rc1
![]() |
||
Updated•15 years ago
|
Keywords: fixed-seamonkey2.0.1
You need to log in
before you can comment on or make changes to this bug.
Description
•